Heads-up: we're also landing a scheduler panel in the Agent UI, salvaged from #517 (NL intervals, REST API, run history in chat sessions). Paths are disjoint from this PR (src/gaia/ui/ vs src/gaia/schedule/), so no mechanical conflicts. Proposed split: this PR keeps the cron core + CLI/sinks, the UI layer lands separately, and we converge on a single store in a follow-up. What's your timeline on this draft?

Heads-up: we're also landing a scheduler panel in the Agent UI, salvaged from #517 (NL intervals, REST API, run history in chat sessions). Paths are disjoint from this PR (src/gaia/ui/ vs src/gaia/schedule/), so no mechanical conflicts. Proposed split: this PR keeps the cron core + CLI/sinks, the UI layer lands separately, and we converge on a single store in a follow-up. What's your timeline on this draft?

Sorry for the delay, it's finals week for me so it's been a bit busy. I'll have this PR done by next Friday at the latest. Also, I was wondering what the single store should be, so I can mold the structure of the scheduling core to it?

No rush — good luck with finals. Next Friday is fine.

On the single store: let's make SQLite the canonical runtime store and keep your TOML as the hand-editable declarative layer on top of it, rather than picking one and dropping the other. Here's the split that lets both surfaces converge cleanly:

• Canonical persistence: the UI scheduler (feat(ui): scheduled recurring tasks in Agent UI #1566) persists schedules to the ChatDatabase (SQLite) and gives each schedule its own chat session for run history. That's the source of truth the daemon reads at runtime, so your daemon.py dispatch loop should ultimately load from it too.
• Your TOML stays as a declarative/import-export format (it's a real CLI virtue — hand-editable, diffable, survives restarts). Think of ~/.gaia/schedules.toml as kubectl apply-style desired state that syncs into the SQLite store, not a competing store.
• Shared Schedule model: align field names so one dataclass serves both. Proposed canonical fields: id/name, cron (canonical schedule expression — the UI parses its NL intervals down to cron so persistence is uniform), prompt, skill, sink/target, enabled, created_at, last_run, next_run, and an optional session_ref linking to the run-history session. Your current model (name/cron/skill/prompt/sink/enabled) is already most of the way there — adding the timestamps + session_ref is the gap.
• Store as an interface: define a small ScheduleStore protocol (load/save/add/remove/get/set_enabled — exactly your current surface), with the SQLite-backed impl from feat(ui): scheduled recurring tasks in Agent UI #1566 as the default and your TOML impl as the file-backed one. That keeps your PR shippable now and makes the follow-up unification a swap, not a rewrite.

So for this PR: keep building the cron core + CLI/sinks against your ScheduleStore, just shape the Schedule dataclass to the fields above so we don't have to migrate it later. The SQLite convergence lands as the agreed follow-up once both this and #1566 are in.

One open question for you: do you want the daemon to own scheduling for both surfaces, or should the UI keep its own in-process scheduler short-term? Happy to sync on that before you finalize.

I think it would intuitively make more sense if the daemon owned scheduling for both surfaces to reduce both scheduling race conditions/double-fires. But making the CLI daemon process the owner has its own trap, as the UI server is already a long-lived process, so if UI schedules only fire when a separate daemon is also up, users get silent no-ops. So I've kept build_scheduler(store) as the single shared engine (it's already a pure function over the ScheduleStore Protocol), and let whichever long-lived process exists host it - the UI server embeds it when running, gaia schedule daemon hosts it headless otherwise. A single-owner guard (lockfile now, or a DB advisory lock once SQLite is canonical) prevents double-fire if both happen to be up. I'd land that lock as part of the SQLite convergence, not this PR.

🟡 store.py:132 — save() is unlocked; mark_run (called by the daemon after every job fire) and CLI writes like set_enabled/remove both do load→modify→save with no file lock. Last writer silently wins, so a gaia schedule pause morning-brief that races a daemon fire can lose the enabled=False update.

# save() with POSIX advisory locking (Linux/macOS)
import fcntl

def save(self, schedules: Dict[str, Schedule]) -> None:
    self.path.parent.mkdir(parents=True, exist_ok=True)
    self.path.touch()
    with open(self.path, "r+b") as f:
        fcntl.flock(f, fcntl.LOCK_EX)
        doc = {"schedules": {s.name: s.to_toml_dict() for s in schedules.values()}}
        f.seek(0)
        f.truncate()
        tomli_w.dump(doc, f)

fcntl is POSIX-only. If Windows support matters here, portalocker is the cross-platform drop-in (one extra dep). The alternative is to note in the docstring that concurrent daemon + CLI writes are unsafe and document the limitation.

Nice work, @TravisHaa — and it tracks the plan from the thread cleanly (canonical Schedule fields in place, so the SQLite convergence is a swap not a rewrite). The no-fallback discipline is solid and APScheduler-over-cron is the right Windows call. Two real things to sort before merge, both about the daemon: scheduled runs can collide on the single Lemonade slot, and the daemon doesn't notice store edits or missed fires. Everything else is nits. One bookkeeping note — the description still lists tests + CLI docs as TODO, but you've actually shipped both; worth updating so they're credited.

CI is all red from pre-existing main failures (a goal_store.py pylint error, a docs-validation issue, Lemonade infra), not your code — a rebase should clear it.

🟡 Two newly-introduced issues:

1. Invalid cron crashes the daemon for all schedules, not just the broken one.
gaia schedule add --cron "not-valid" ... succeeds silently, but when the daemon starts, build_scheduler calls CronTrigger.from_crontab(schedule.cron) for every enabled schedule in a tight loop — one invalid entry raises and aborts the loop, so all other valid schedules never get armed. The fix is to validate the cron at add time (call CronTrigger.from_crontab(args.cron) before store.add) so bad expressions are rejected immediately with an actionable error.

2. Telegram bot token can leak into logs via requests exception messages.
When requests.post(url, ...) raises a RequestException (network failure, DNS timeout, etc.), the requests library includes the full URL — "/botTOKEN/sendMessage" — in the exception string. That {e} is embedded into the RuntimeError message, which then propagates to daemon._job's log.exception("schedule %r failed", ...), printing the full traceback (including the chained cause) to the log file. Fix: don't embed {e} directly; log a sanitized message that names the host without the token-bearing path.

from apscheduler.triggers.cron import CronTrigger

if action == "add":
    try:
        CronTrigger.from_crontab(args.cron)
    except ValueError as e:
        print(f"Invalid cron expression {args.cron!r}: {e}", file=sys.stderr)
        return
    ...
    store.add(schedule)

# current (leaks token via {e})
except requests.RequestException as e:
    raise RuntimeError(
        f"telegram sink could not reach {TELEGRAM_API}: {e}. ..."
    ) from e

HTTPSConnectionPool(host='api.telegram.org', port=443): Max retries exceeded with url: /botSECRET_TOKEN/sendMessage

except requests.RequestException as e:
    raise RuntimeError(
        f"telegram sink could not reach {TELEGRAM_API} (sendMessage). "
        f"Check network connectivity."
    ) from e